1. Field of the Invention
The invention relates to computer security and more particularly to techniques for implementing a security on small footprint devices, such as smart cards.
2. Description of Related Art
A number of object oriented programming languages are well known in the art. Examples of these include the C++ language and the Smalltalk language.
Another such object oriented language is the JAVA(trademark) language. This language is described in the book Java(trademark) Language Specification, by James Gosling et al. and published by Addison-Wesley. This work is incorporated herein by reference in its entirety. The JAVA(trademark) language is particularly well suited to run on a Java(trademark) Virtual Machine. Such a machine is described in the book Java(trademark) Virtual Machine Specification, by Tim Lindholm and Frank Yellin which is also published by Addison-Wesley and which is also incorporated herein by reference in its entirety.
A number of small footprint devices are also well known in the art. These include smart cards, cellular telephones, and various other small or miniature devices.
Smart cards are similar in size and shape to a credit card but contain, typically, data processing capabilities within the card (e.g. a processor or logic performing processing functions) and a set of contacts through which programs, data and other communications with the smart card may be achieved. Typically, the set of contacts includes a power source connection and a return as well as a clock input, a reset input and a data port through which data communications can be achieved.
Information can be written to a smart card and retrieved from a smart card using a card acceptance device. A card acceptance device is typically a peripheral attached to a host computer and contains a card port, such as a slot, in to which a smart card can be inserted. Once inserted, contacts or brushes from a connector press against the surface connection area on the smart card to provide power and to permit communications with the processor and memory typically found on a smart card.
Smart cards and card acceptance devices (CADS) are the subject of extensive standardization efforts, e.g. ISO 7816.
The use of firewalls to separate authorized from unauthorized users is well known in the network environment. For example, such a firewall is disclosed in U.S. patent application Ser. No. 09/203,719, filed Dec. 1, 1998 and entitled xe2x80x9cAUTHENTICATED FIREWALL TUNNELLING FRAMEWORKxe2x80x9d in the name of inventor David Brownell, which application is incorporated herein by reference in its entirety.
A subset of the full Java(trademark) platform capabilities has been defined for small footprint devices, such as smart cards. This subset is called the Java Card(trademark) platform. The uses of the Java Card(trademark) platform are described in the following publications.
JAVA CARD(trademark) 2.0xe2x80x94LANGUAGE SUBSET AND VIRTUAL MACHINE SPECIFICATION;
JAVA CARD(trademark) 2.1xe2x80x94APPLICATION PROGRAMMING INTERFACES;
JAVA CARD(trademark) 2.0xe2x80x94PROGRAMMING CONCEPTS;
JAVA CARD(trademark) APPLET DEVELOPER""S GUIDE.
These publications are incorporated herein by reference in their entirety.
A working draft of ISO 7816xe2x80x94Part 11 has been circulated for comment. That draft specifies standards for permitting separate execution contexts to operate on a smart card. A copy of that working draft is hereby incorporated by reference in its entirety.
The notion of an execution context is well known in computer science. Generally speaking, the use of multiple execution contexts in a computing environment provides a way to separate or isolate different program modules or processes from one another, so that each can operate without undue interference from the others. Interactionsxe2x80x94if anyxe2x80x94between different contexts are deliberate rather than accidental, and are carefully controlled so as to preserve the integrity of each context. An example of multiple contexts is seen in larger hardware devices, such as mainframes, where a plurality of virtual machines may be defined, each such virtual machine having its own execution context. Another example is seen in U.S. Pat. No. 5,802,519 in the name of inventor De Jong, which describes the use of multiple execution contexts on a smart card. It will be appreciated by those of skill in the art that a computing environment which provides multiple execution contexts also needs to provide a mechanism for associating any given executing code with its corresponding context.
Also well known is the notion of a current context. Certain computing environments that support multiple contexts will, at any given time, treat one context in particular as an active focus of computation. The context can be referred to as the xe2x80x9ccurrent context.xe2x80x9d When the current context changes, so that some other context becomes the current context, a xe2x80x9ccontext switchxe2x80x9d is said to occur. As will be appreciated by those of skill in the art, these computing environments provide mechanisms for keeping track of which context is the current one and for facilitating context switching.
In the prior art, in the world of small footprint devices, and particularly in the world of smart cards, there was no inter-operation between contexts operating on the small footprint devices. Each context operated totally separately and could operate or malfunction within its context space without affecting other applications or processes in a different context.
One layer of security protection utilized by the Java(trademark) platform is commonly referred to as a sandbox model. Untrusted code is placed into a xe2x80x9csandboxxe2x80x9d where it can xe2x80x9cplayxe2x80x9d safely without doing any damage to the xe2x80x9creal worldxe2x80x9d or full Java(trademark) environment. In such an environment, Java(trademark) applets don""t communicate, but each has its own name space.
Some smart card operating systems don""t permit execution contexts to communicate directly, but do permit communications through an operating system, or through a server.
The Problems
A number of problems exist when trying to place computer programs and other information on a small footprint device. One of the compelling problems is the existence of very limited memory space. This requires often extraordinary efforts to provide needed functionality within the memory space.
A second problem associated with small footprint devices is the fact that different small footprint device manufacturers can utilize different operating systems. As a result, applications developed for one operating system are not necessarily portable to small footprint devices manufactured by a different manufacturer.
If programs from more than one source of programs (manufacturer or vendor) are to be applied to a single small footprint device, security becomes a factor as one attempts to avoid corruption of existing programs and data when a new program is loaded on to the small footprint device. The same concern exists when one wishes to prevent a hacker or a malicious person from accessing programs and data.
It is clear that small footprint devices such as smart cards don""t have the resources necessary to implement separate virtual machines. Nevertheless, it is desirable to maintain strict security between separate execution contexts.
In the past, security was provided by loading only applications from the same source or from a known trusted source onto a smart card or other small footprint device.
Accordingly, it would be desirable to allow object-oriented interaction between selected execution contexts only in safe ways via fast efficient peer to peer communications which do not impose undue burdens on the programmer but facilitate dynamic loading of applets written at different times by untrusted sources.
The invention is directed to providing a context barrier (sometimes referred to as a firewall) for providing separation and isolation of one context from another and to provide controlled access across the barrier when that is needed.
In accordance with the invention, two execution contexts, e.g. each containing one or more applets, running in the same logical (i.e., virtual or real) machine, protected from each other, can share information in a controlled, secure way, using language mechanisms, such as object-oriented language mechanisms. Security can be, for example, object by object. Thus, a method in a first execution context can access a first object A in a second execution context, but not a second object B in the second execution context on a selective basis.
In accordance with one exemplary embodiment, an enhanced Java(trademark) Virtual Machine (VM) provides certain run-time checks of attempted access across execution contexts in the VM. Checks can be automatic by the VM or coded by the programmer with support from the VM. This can be done using language-level communication mechanisms. In this way, one can express object access across execution contexts in the same way as other object accesses using the language are made. These run-time checks provide a second dimension of defense/security beyond that which the Java(trademark) language and platform already provide.
These mechanisms provide protection against, e.g., security holes due to programming bugs (such as declaring a datum xe2x80x9cpublicxe2x80x9d (global) when it shouldn""t be accessible to all contexts). They also allow fine-grain control of sharing (such as selection of objects to share and applets to share to).
The invention is also directed to computer program products and carrier waves related to the other aspects of the invention.
The foregoing and other features, aspects and advantages of the present invention will become more apparent from the following detailed description of the present invention when taken in conjunction with the accompanying drawings.